In many scenarios messages are targeted directly to a Web service. In such a scenario, the message addressing information can be described simply using a GUID or URL of the service (service address), the address of the message sender is identified by the transport mechanism (e.g., TCP/IP, HTTP, etc.) being used to send the message. For example, a client service might send a request to a printing service and receive an acknowledgement that that the request was received. At a later point in time the printing service might want to notify the client service that the printing request has been serviced. Using conventional request/response addressing mechanisms, such as a transport-based binding to Simple Object Access Protocol (SOAP) to leverage the transport's request/response mechanism to carry the response, addressing information needed to send a message back to the client service is available until the transport channel closes. The printing service of this example can generally use this addressing information to send a request back to the intended recipient.
In practice, however, a service or other entity within the service often needs to target a message to specific elements or resources within a Web service wherein the target address is not so simply provided by the a message transport's request/response mechanism. For instance, in the above example of the printing service, if the client service wants the printing service to notify a third party (independent from the client service) when a printing request has been serviced, the address of the third party is generally communicated to the service independent of the messaging transport response/request mechanism. Such non-standard addressing information is typically encoded in an ad-hoc manner within a GUID or URL of the service. Unfortunately, embedding addressing information within the GUID or URL of the service is substantially limited and problematic.
One limitation, for example, is that serialization of addressing information within a 128-bit GUID or URL substantially restricts the format and quantity of the additional information being conveyed. Additionally, when non-standard data is serialized into a service GUID or URL of the service, the service must share a common set of assumptions with the message originator about how the non-standard data is to be parsed or extracted from the GUID or URL of the service, and subsequently managed. Such tight coupling between components is undesirable because tightly coupled components are generally more expensive and time consuming to create and maintain. This example illustrates that conventional Web service messaging techniques do not provide a satisfactory technique to identify specific elements within a service that send or should receive a message, wherein the elements cannot be simply defined by a standard request/response messaging paradigm.
The immediately preceding limitation and problem of ad-hoc encoding of non-standard addressing information into a service GUID or URL is directly related to another problem of conventional Web service communications. The related problem surfaces when a message originator wants to a service coordinator (e.g., an event source) to add context to a message targeted to a service recipient (e.g., an event sink as part of an event notification subscription, a gateway, firewall, etc). As with addressing information that does not fall neatly into the request/response transport messaging mechanism, message context is also typically encoded in an ad-hoc manner within the GUID or URL of the service. Such ad-hoc embedding of context into a GUID or URL data field has all of the limitations and problems associated with ad-hoc encoding of non-standard addressing information in such a data field—restricted format and quantity of the context being conveyed and the need to share common assumptions between components resulting in undesirably tight coupling between the parsing entity and the message originator. This example illustrates that conventional Web service messaging techniques do not provide a satisfactory technique to communicate message context to message recipients.
To make matters worse, every time the amount and/or the data format of such non-standard embedded data (addressing information, context, etc.) changes, it is likely that the service will need to be modified to properly parse and extract the new context style from the GUID or URL of the service address. These and other problems of conventional network communications are addressed by the following systems and methods for open content model Web service messaging.